1. Technical Field
The present invention relates to an improved data processing system. In particular, the present invention relates to a monitored application in a data processing system. Still more particularly, the present invention relates to exposing monitoring violations to monitored applications in a data processing system.
2. Description of Related Art
Performance monitoring is often used in optimizing the use of software in a system. A performance monitor is generally regarded as a facility incorporated into a processor to assist in analyzing selected characteristics of a system by determining a machine's state at a particular point in time. One method of monitoring system performance is to monitor the system using a transactional-based view. In this manner, the performance monitor may access the end-user experience by tracking the execution path of a transaction to locate where problems occur. Thus, the end user's experience is taken into account in determining if the system is providing the service needed. Another method of monitoring system performance is to monitor the system based on resources. For example, by monitoring usage of the central processing unit (CPU) or memory consumption, problem areas may be identified based on the amount of resources consumed by each process currently running in the system.
Transaction monitoring systems, such as Tivoli Monitoring for Transaction Performance™ (hereafter TMTP), monitor the availability and performance of Web-based services and operating system applications. Such systems capture detailed transaction and application performance data for all electronic business transactions. In this way, every step of a user transaction as it passes through an array of hosts, systems, applications, Web and proxy servers, Web application servers, middleware, database management software, and legacy back-office software, may be monitored and performance characteristic data compiled and stored in a data repository for historical analysis and long-term planning.
One way in which this data may be compiled in order to test the performance of a system is to simulate user transactions and collect “what-if” performance data to help assess the health of electronic business components and configurations. In addition to high level user transactions, sub-transactions of a user transaction may also be monitored. For example, from a user request of a Web page in a Web browser, to a servlet in a Web server, to an EJB within an application in an application server, to a Java class that implements the EJB and to a Java method of the Java class.
Transaction monitoring systems link user transactions and sub-transactions using correlating tokens, such as ARM (Application Response Measurement) correlators. ARM is a standard for measuring response time and status of transactions. ARM employs an ARM engine, which records response time measurements of the transactions. For example, in order to measure a response time, an application invokes a ‘start’ method using ARM, which creates a transaction instance to capture and save a timestamp. After the transaction ends, the application invokes a ‘stop’ method using ARM to capture a stop time. The difference between a start and stop time is the response time of the transaction. More information regarding the manner by which transaction monitoring systems collect performance data, stores it, and uses it to generate reports and transaction graph data structures may be obtained from the Application Response Measurement (ARM) Specification, version 4.0, which is hereby incorporated by reference.
In addition, transaction monitoring systems pass correlating tokens in user transactions to allow for monitoring the progress of the user transactions through the system. As an initiator, a transaction may invoke a component within an application and this invoked component can in turn invoke another component within the application. Correlating tokens are used to “tie” these transactions together.
In addition to correlating tokens, transaction monitoring systems also leverage a programming technique, known as aspect-oriented programming (AOP), for defining start and stop methods of the transactions in order to measure performance. Aspect-oriented programming techniques allow programmers to modularize crosscutting concerns by encapsulating behaviors that affect multiple classes into reusable modules. In other words, AOP identifies common problems or traits in multiple modules or objects and applies a common behavior across all of the modules without rewriting the code individually for each and every module.
Some transaction monitoring systems, such as TMTP, employ an implementation of the aspect-oriented programming technique, such as just-in-time-instrumentation (JITI), to weave response time and other measurement operations into applications for monitoring performance. JITI provides the ability to manipulate the byte code of a monitored Java application at runtime in a manner similar to Byte Code Engineering Library (BCEL). BCEL allows developers to implement desired features on a high level of abstraction without handling all the internal details of the Java class file format. JITI adds new byte codes to the monitored application classes to provide hooks, such that the monitoring application may run in a manner similar to aspect-oriented programming tools, such as AspectJ.
Using JITI or other prior art instrumentation techniques and ARM correlators, transaction monitoring systems allow users to dynamically monitor transactions and to define thresholds against those transactions. A threshold is a limit of performance or availability that is acceptable by the user. For example, a user may define a threshold of response time, which is the highest number of seconds a transaction may take. In this way, companies can specify availability of their applications at a certain service level agreement (SLA). If the response time measured exceeds the threshold of a policy, transaction monitoring systems notify the user of the performance problem, and the user may take appropriate action to correct the problem. The use of transaction monitoring systems helps decompose large business transactions into hundreds of sub-transactions. In addition, performance problems may be identified using the thresholds.
While transaction monitoring systems provide prompt and automated notification of performance problems when they are detected, this notification is only available to the monitoring application itself. The application that is being monitored, or the monitored application, does not have the capability to detect that it is being monitored by a monitoring component. In addition, the monitored application does not have the ability to detect a transaction performance violation.
An example of a monitored application is a user application, such as a banking application that is implemented as a J2EE application running on a WebSphere Application Server. Websphere Application Server, a product available from International Business Machines Corporation, is a J2EE application server that provides an operating environment for e-business applications to perform transactions over the Internet. Currently, the user has to launch the monitoring application, such as transaction monitoring systems, to view the transactions and the logging that is associated with the monitored application.
Therefore, it would be advantageous to have an improved method, apparatus, and computer instructions for exposing monitoring violations to the monitored application, such that the monitored application may autonomically detect that a monitored application is applied and take custom corrective actions to solve the problem if a violation occurs.